Read images with deepseek-v4-flash-vision-exp, and move DeepSeek onto the Responses protocol - #185

DeepSeekV4Client now calls /responses instead of /chat/completions: it reads the
reasoning_text, output_text and function_call_arguments deltas, rebuilds a
replayed chain of thought as a reasoning item whose content is reasoning_text,
and takes usage from input_tokens/output_tokens with their detail blocks.

thinking_level maps to reasoning.effort pre-collapsed to what DeepSeek settles on
(none/low/high/high/high/max); effort "none" is what disables thinking there,
since the Chat Completions thinking toggle is ignored on this endpoint. The
temperature, tool_choice, fast_mode and prompt_caching restrictions are unchanged.

An image_url item is sent as an input_image part and a tool result's images ride
in the function_call_output, so a tool can hand the model a picture it produced.
A model without vision refuses the item instead: Chat Completions answers 400,
but the Responses API silently swaps the image for placeholder text.

Both this client and OpenaiResponsesClient now flush the message text collected
so far before appending a reasoning, function_call or function_call_output item.
An assistant turn that spoke before calling a tool used to replay as call, then
text, then output, which DeepSeek answered with "No tool output found for tool
call <id>" on the next turn.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

The four protocol suites fed DeepSeek chat-completion chunks through a fake
.chat.completions endpoint, which the Responses client no longer calls. The
DeepSeek case moves to the Responses shape in each: the stream-case lists carry a
protocol field, the fakes install either endpoint, and the empty-response and
tool-call-argument suites gained a case for the generic openai-responses client
beside it. The thinking-level table now expects effort "none" for NONE, which is
how thinking is disabled on this endpoint.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

…-chat

The vision model joins the registry on the official API with Text, Image input, a
1M context window and the deepseek-v4-flash price (CNY 1.5 / 4.5 per million
tokens off-peak, 0.05 on a cache hit; peak rates are double). It replaces
deepseek-v4-flash as the official DeepSeek entry in both E2E model lists with
image understanding enabled, which brings the URL, base64 and tool-result image
tests with it; the three protocol-mode entries stay on deepseek-v4-flash.

deepseek-ai/DeepSeek-V4-Flash and deepseek-ai/DeepSeek-V4-Pro move to the generic
openai-chat client, since api.siliconflow.cn serves no /responses endpoint. The
OpenRouter entries keep the deepseek-v4 client, which its /responses does serve.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

…ocol section

The Responses transforms decide once, at the top of the item loop, that anything
which is not message content flushes the text collected so far; the branch chain
below is the one it had before. The continue-based split said the same thing in
more places.

In the README the three generic protocol clients become a list, the supported-model
listing gets a Python and a TypeScript snippet, the client-type-to-protocol table
moves below both, and openai-embedding is code-formatted like the other protocols.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

…h tests

GPT5_6Client and MiniMaxM3Client deferred the assistant message to the end of the
item loop the same way the other two Responses clients did, so an assistant turn
that spoke before calling a tool replayed as call, then text. Both now flush the
collected text before appending a standalone input item.

The audit of the remaining clients found nothing else: Claude and the Anthropic
protocol client build one ordered content block list, Gemini one ordered parts
list, and Chat Completions carries no interleaving at all, since the text lands in
content and the call in tool_calls of the same message.

test_message_order.py and message-order.test.ts run a thinking-text-tool_call turn
through all ten clients with a fake key and assert the emitted order per protocol.
Against the pre-fix tree the four Responses cases fail and the other six pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

…down

An "unused" event is a client's own marker for a wire event that carries nothing
universal. No client yields one today, but nothing guaranteed it: streaming_response
now drops one that escapes and raises on it under AGENTHUB_DEBUG, so a client that
forgets its filter fails in CI instead of shipping empty events to a caller.

The EventType definition says what the four kinds mean, and the development skill
records both client rules it had only in code: unused stays inside the client, and
the message transform keeps the order of the content items.

The unknown-event suites now run every client over the ignorable events its protocol
carries with the debug guard on, and a deliberately leaky client covers the drop and
the raise.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBwEdjegVGtfY2yJKwhZ77